With the decreasing cost and increasing power of microcontrollers, it has become common to use them as individual processing modules for all sorts of complex information gathering, processing, and displaying functions, as well as for controlling the operation of systems of all types. Microcontrollers are typically used in two different ways. In the first of these, they are embedded in a system along with ROM (read only memory) in which dedicated software instructions are permanently held, and with a modest amount of RAM (random access memory) for holding operand values for short periods of time. An embedded microcontroller and its software usually comprise only a single processing module. These microcontrollers are also used as the processing element in the extremely common personal computers having large disk memories, a large RAM, and a keyboard and display unit for communication with a human. A personal computer can hold a number of separate software applications and operate these more or less simultaneously in a multitasking mode. By "multitasking" is meant that instruction execution proceeds for one software application for a period of time, and then is transferred to another application. An external event or simply the passage of a prescribed period of time may transfer execution of instructions from one to another application. The appearance is thus created that a number of multitasked applications are operating simultaneously, even though two instructions from two different applications are typically not executed precisely simultaneously. Each of the multitasked applications can be considered a separate processing module, in that each has an independent existence. As a practical matter, it is frequently possible to perform a particular function with a processing module of either of these types.
It is common to employ a number of these processing modules in a single system, each of them dedicated to a specific function or group of functions. These processing modules may each comprise a separate microcontroller. It is also possible to have a number of different software applications of a single system operating in this multitasking mode within a single microcontroller, each software application also comprising a processing module. It is also possible to have a hybrid system, comprising a personal computer with a number of software types of processing modules along with a number of embedded microcontrollers also performing functions in the system. There are a number of advantages in dividing the computing burden in this way. Some functions are more effectively performed with one type of processing module, some with others. It is possible that there are uses for certain types of processing modules in different types of systems, and by modularizing the function, can be more easily transferred between the systems. Also, modular systems can be more easily analyzed when the inevitable errors arise, in that there are well-defined inputs and outputs lending themselves to easier access.
In order to coordinate the activities of these processing modules, it is useful to connect the individual processing modules of a larger system which perform these functions in a way which allows transfer of data among the processing modules. Where these processing modules are separate microcontrollers, they may be interconnected by cabling over which data is transferred. Many different types of arrangements permitting efficient and reliable transfer of data between a number of embedded or stand-alone processing modules have been designed. This problem is not trivial. Where the processing modules are multitasked software applications, it is of course possible to establish protocols allowing these processing modules to communicate with each other. Since only one at a time is typically active, the problem is somewhat simpler.
The data involved will typically indicate some quantity or value to which the processing module has access say through external sensors or which the module generates during its processing operations. This data will typically comprise discrete elements, and each of these elements of data will be referred to as a data item. For example in an environment control system, ambient air temperature may be a data item. Status, open or closed, of a valve controlling flow of fuel or refrigerant may be another data item. The result of a calculation may be another example of a data item. A data item may be generally considered to be a particular data element which has some digital value. A data item will typically also have an identity code which uniquely identifies it, since a source for a data item value may well be able to provide a number of different data items values.
As a system becomes more complex, the number of data items available will usually become large. In most cases, one processing module will have need for only some of the data item values which another of the processing modules has available. For example, a furnace controller may not need to have access to the temperature of the controlled space. All that it may need from the temperature control processing module is a demand flag which is set whenever the furnace must operate. One way to address the problem arising from transferring data unnecessarily between processing modules is to establish the protocol that one processing module will transmit a data item value to another only when requested. To follow the example from above, the furnace controller may request the demand flag data item every second or so from the temperature controller, and then based on its value will start up, shut down, or continue the current status of the furnace. In such a system, the processing module initiating a request signal is known as the client, and the processing module to which the request signal is sent is known as the data source, or simply "source". In an appropriate system, a particular processing module may be a client with respect to one request signal and a source with respect to another.
As the communication and control required by physical systems have become greater, the connections between the processing modules involved with these systems have become increasingly complex. If there are a large number of either clients or sources, it is not practical to have individual data paths from each of the modules to every other module. The situation may be complicated even more by the fact that the replies from data sources to requests may proceed very slowly compared to the internal speed of the clients because of high traffic levels on the data paths involved or because of slow processing speed for one or another reason on the part of the data source. The fact that individual processing modules may be physically spaced a substantial distance from each other and connected by a telephone modem is one obvious cause for slower speed. For all of these reasons, it has been found that it is sometimes more efficient to route all of the requests for data items and the replies to them through a single processing module. This routing function is one made to order for the high data handling capabilities of the small and cheap but powerful desktop computers now available. Where at least one of the processing modules in the system is already implemented within a desktop computer, it is convenient and cheap to devise a processing module which operates within that desktop computer, for directing and routing processing module communications.
The computer in which operates the processing module redirecting the client requests to the various sources and receiving and replying with the data item values, will be called the server computer, whether serving as the host for clients or data source applications or not. That is, in the case where client or source processing modules are multitasked software applications, the host computer in which the client or source applications execute may also be the server.
These host computers use an operating system of some type to accomplish the various communication and control functions which are a necessary adjunct to the application programs. For the IBM compatible types of computers, the most widely used of these operating systems is DOS. It is now usual for the more powerful types of these computers to use a higher level graphics-based operating system to accomplish many of these communication and control functions. For IBM compatible computers, this graphics-based operating system is known as "Windows". The function set available from the Windows operating system is much larger than that of DOS, but Windows uses many of the functions in DOS in implementing its own functions. Both DOS and Windows include a number of utility routines which are available to all of the application programs to perform common software communication and other functions, thereby freeing each of the users from having to individually replicate these frequently used functions. Certain of these utility routines will be mentioned in the description which follows.
The Windows operating system, recognizing the need for communication among the applications resident in the host computer, includes a function known as Dynamic Data Exchange (DDE) which allows one application program to request data items from another. In this function, an application provides a request to the Windows system identifying another application and the data item desired from it. The Windows system DDE function then requests that data item from the designated application, and responds to the requesting client application with that data item. A protocol is provided for this function which specifies such matters as formats of requests and replies, timing requirements, and error management. DDE data requests are of two types. One type is called a cold link, where a client request requires only a single response. The other type is a hot link, where a single request causes an immediate response, and then further responses at intervals specified by the hot link request, until the requesting client closes down the hot link request. Since each hot link periodically requires additional processing time, it is in no application's interest for a hot link to exist if unneeded. Therefore, as the need for a particular data item disappears, the requesting application should close down the hot link request, and this is customary.
The DDE function is intended for use where the data links between both the clients and the sources are host computer software processing modules, and therefore relatively fast. We have found that the DDE mechanism can also work reasonably well in a situation where the requested information is provided by the external sources mentioned above, rather than by application programs within the host computer. In one situation, the routing computer may be considered to include a single multiplexer or gateway to which is connected a number of data sources, each of which can have a relatively large number of data items available. A request (hereafter "source request") supplied to the gateway specifies the data source connected to the gateway and the specific data item value desired from that gateway. The gateway will send its own request to the specified data source and receive in reply the data item value from the data source in a data source reply. Because of the relative slowness of replies from the individual data sources and the extra gateway stage for both request and reply however, there is a substantial delay of at least several tenths of a second, and perhaps even several seconds, for the server to receive the data source reply sent in response to each request.
If client requests are relatively infrequent and the data link to the source is fast, the server can provide the requested information to clients relatively promptly. When a client request arrives, the routing computer simply sends the appropriate data source request via the gateway to the source from which the data item value is available. When the data source reply is returned to the routing computer, it passes the data item value therein on to the requesting client per the usual DDE procedure. Each data source reply includes a number of other parameters. These identify the data item value, the client which originated the client request to which the reply is directed, etc.
The server must be able to deal with the situation where a number of client data requests are pending at a particular time. This happens frequently where the gateway is of the type which accepts only a single source request at a time, but it can also happen where the volume of client requests exceeds the processing speed of the gateway. In such a situation, replies to client requests are delayed, perhaps to an extent where the data item value is worthless to the client when it is finally received. In the situation where the long term rate of client requests is greater than the capacity of the gateway or data sources to respond, then client requests will simply be lost since the table in which they are stored can have only finite capacity, and the entries will continue to grow. Thus, it would extremely valuable to be able to limit the number of source requests without limiting the number of replies sent to the clients.